复盘寻找 AI 全能王”阿里云 Data+AI 工程师全球大奖赛
“寻找 AI 全能王”阿里云 Data+AI 工程师全球大奖赛：Agent 构建挑战赛第 8 名，初赛成绩 0.686869，复赛成绩 0.52。
本次比赛的题目要求是构建一个能够在 100 道复杂题目上尽可能稳定作答的 Research Agent。题目覆盖事实验证、多跳推理、时间约束、实体对齐、语言格式约束，以及部分数字和单位类问题。
1. 设计思路
我们团队开始参与比赛的时间比较晚，所以一开始的设计比较仓促：让 AI 根据题目要求设计了一个能跑的架构，就开始编码实现。赛后（甚至赛中）回过头来看，制约我们上限的根源就在这里。
其实在几个月前，团队成员曾系统性地对 Agent/Multi-Agent 的 Planning 做过调研，但习得成果并没有很好地沉淀为实际工程开发能力。
我们设计的 Agent 有 3 个核心组件：负责规划的 Planner、负责联网搜索的 Searcher、负责多轮推理的 Reasoner。回答问题的基本流程如下：
- 首先由 Planner 对问题做 Hop-1 规划：提取高信息量线索，区分“第一步该解决的未知数”和“后续再验证的条件”，只生成首轮搜索计划，而不是直接尝试回答整道题。
- 接着由 Searcher 根据 Planner 生成的查询进行首轮并行搜索。这里采用混合检索策略，同时结合语义搜索和关键词搜索，从多个搜索源召回候选证据，并对结果进行清洗、去重和压缩，形成初始证据集合。
- 然后将“问题本身 + Planner 的意图 + 首轮检索到的初始证据”一并交给 Reasoner。Reasoner 进入多轮推理循环，先根据已有证据判断当前最可能的候选实体或结论，再决定是否需要发起下一轮搜索。
- 如果信息仍然不足，Reasoner 会继续调用 Searcher 做补充检索，逐步完成实体确认、关系验证、时间核对和答案对齐，直到满足作答条件。这个阶段本质上是一个带工具调用的 ReAct 式推理过程。
- 当 Reasoner 认为证据已经充分时，输出最终答案，并由系统提取最终结论返回给用户或写入评测结果。
2. 赛中挣扎
按上述设计实现的 Agent，实际跑分效果并不好。初赛阶段只能得到 0.3-0.5 的分数，且由于搜索工具和大模型黑盒的不稳定性，多次跑分差异也较大。
为了提高复赛中的稳定性，我们不断加入多种兜底机制，包括首轮搜索失败后的泛化回退、搜索结果去重与截断、工具调用异常重试，以及模型未正确调用工具时的补救处理。
我们认为，决定 Research Agent 准确率的四大因素是：模型能力、Agent 架构、联网搜索策略和提示词工程。在紧张赛程内再次调整整体架构已不太可行，所以我们把时间和精力集中到后两点上。
2.1 关于联网搜索工具
我们采用了混合检索策略：Exa 用作语义搜索，Serper 用作通用关键词搜索，IQS 用作结构化短关键词搜索。这样并行搜索、多源召回能够在兼顾速率与成本的同时，取得较高的准确率和稳定性。
同时，中文和英文题都可以通过 language、结构化 query 和搜索引擎差异获得互补召回。
实际测试中我们发现，联网搜索结果很容易受到模型风控影响，导致最后推理总结被强制中断，输出结果为空。直到比赛结束我们也没有找到好的解决方案。
现在回头看，一个可行的改进方向是在 Searcher 与 Reasoner 之间增加“证据净化与结构化事实抽取层”，并在风控触发后切换到更保守的检索与作答模式，以降低模型暴露于高风险文本的概率。
2.2 关于提示词
提示词的持续迭代对 Agent 质量提升效果显著。为了规范模型输出、对齐测试结果和参考答案一致性，我们在提示词中加入了许多约束、边界条件和 few-shot。
整个流程里有 2 段核心系统提示词：Planner 提示词和 Reasoner 提示词。
2.3 关于迭代
在刚参赛时，我们优先选择以一个简单 demo 先跑通阶段二的平台流程。最初 demo 选择了 qwen-max 和 ReAct 架构为核心，但第一次提交成绩时，这个 demo 在阶段 1 的 ACC 十分惨淡，仅有 11% 左右。
后续调试时发现，完全相同的代码下，qwen-3.5-plus 取得了更优异的成绩（50%+），且费用显著降低，因此我们最终选定 qwen-3.5-plus 作为基模。
确定模型后，针对 Agent 架构进行了优化迭代：从最初单一角色增加到 Planner、Researcher、最终整理输出格式的三角色架构，并从 Qwen、Gemini 等领先应用在多跳推理上的处理链路中“蒸馏”提示词策略，包括交叉验证、聚焦核心实体、提取高熵关键词、搜索策略优化等。
对异常情况的处理是最后两天最大的折磨。在冲榜迭代 agent_loop 时，我们发现 qwen-3.5-plus API 在开启 thinking 模式时，常出现模型输出中既无 <tool_call> 也无 <answer> 的情况，而真正的 <tool_call> 会在 thinking 中以伪代码形式输出。
另外，搜索引擎返回内容不当会高频触发 data_inspection_failed 错误。这两类异常出现概率约 25%+，即 100 题中大约有 25-30 题会出现类似问题。由于开发经验不足，我们在归因和修复上浪费了很多时间；且最后方案偏“打补丁”，效果有限，结果也比较遗憾。
3. 总结反思
- 封装更强大的工具类，如单位换算、数值计算、数据清洗等。
- 对“最后一跳结果”与“题目要求”的对齐不能仅依赖提示词，更应通过结构优化实现检查和回退。
- 日志能力欠缺：某个问题回答错误时，只能依赖手动查找平台日志 debug。
- 工程上仍不成熟：前期调研和学习不充分，Agent 开发问题处理经验不足，团队协作经验也较少，三人精力分配过于分散。
- 基模能力是限制 Agent 的关键因素。同样的 Agent 框架，仅基模不同，ACC 差距可能非常大。
- 有时复杂架构效果反而更差，轻量架构可能更优；应以日志和实测结果为依据判断是否调整架构。
- 一定要养成保存代码的习惯，尤其在大改架构时，避免效果不佳后无法回退。
- 团队分工要明确，责任边界要清晰。
源码现已开源，欢迎 star 和二开：
https://github.com/Liangchenrui/Research-Agent-Alibaba-Cloud-Competition-202603
4. 致谢
感谢阿里云和通义团队提供的平台与模型支持，感谢北京邮电大学自邮之翼团队提供的比赛经费支持。